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© Distributed file system 



© A distributed file system uses objects to model 
the behavior of components of the distributed file 
system. Each object has an associated logical path 
name and physical address. An aggregation of all 
the logical path names comprises a distributed name 
space which can be logically partitioned into do- 
mains. Each domain includes a domain folder object 



which maps logical path names of objects in the 
domain containing the domain folder object, into 
addresses in the distributed system where the ob- 
jects are stored. The addresses of the objects are 
used to access the objects in order to retrieve in- 
formation from the distributed system. 
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Technical Field 

This invention relates generally to file systems 
and, more specifically, to a distributed file system 
for a distributed system. 

Background of the Invention 

Existing distributed systems provide distributed 
file systems which are capable of retrieving files 
from different locations throughout the distributed 
system. Existing distributed systems gain access 
to files by mapping a logical path name which 
uniquely identifies the file into a physical address 
at which the file is stored. The logical path name of 
the file is intrinsically tied to the physical address 
of the files. 

As the size of the distributed system increases 
it becomes more difficult, due to the sheer number 
of logical path names active in the distributed sys- 
tem, to manage the logical path names in a way 
which provides for efficient mappings of logical 
path names into physical addresses. In addition, it 
becomes more difficult to provide a single, consis- 
tent name space to a user of the distributed sys- 
tem from any location on the distributed system. 
Prior systems have instead provided a fragmented 
name space to users of the distributed system. 

Summary of the Invention 

The difficulties of the prior art are overcome by 
the present invention. In accordance with one as- 
pect of the present invention, a distributed system 
has a distributed name space of objects wherein 
each object has both a logical name that uniquely 
identifies the object and a corresponding address. 
The objects are grouped into logical domains which 
are organized into a hierarchical structure. Each 
domain may have a superior domain in the hierar- 
chical structure and may have one or more subor- 
dinate domains in the hierarchical structure. A do- 
main controller component is provided for each 
domain. Each domain controller component holds a 
cache such as a prefix table. The cache holds an 
entry for a logical name in the distributed name 
space for a domain controller component for any 
immediately superior domain. In addition, the 
cache also holds an entry for the logical name in 
the distributed name space for a domain controller 
in any immediately subordinate domains. Each en- 
try for the above discussed domain controller com- 
ponents includes an address for the domain con- 
troller component. 

A first computer component is provided in the 
distributed system for processing requests for in- 
formation from the distributed system. The first 
computer component includes a second cache 



which stores entries for portions of the logical 
names in the distributed name space. Each entry 
includes an address of an object in the distributed 
system that is identified by the associated portion. 

s The request is to access an object at the first 
computer component is received. The request in- 
cludes a logical name corresponding to the object 
in the distributed system. It is determined whether 
a portion of the logical name is stored in the cache 

jo of the first computer component. Where it is deter- 
mined that there is not an entry for a portion of the 
logical name in the cache of the first computer 
component, several steps are performed. 

First, the address of the domain controller 

is component for the domain containing the first com- 
puter component is retrieved from the cache of the 
first computer component. The logical name is sent 
to the domain controller component that contains 
the first computer component. An address cor- 

20 responding to the logical name of the object is 
retrieved from the cache of the domain controller 
component for the domain containing the first com- 
puter component. The object is then accessed at 
the retrieved address. 

25 In accordance with another aspect of the 

present invention a distributed system has a first 
storage media partition and a second storage me- 
dia partition. A first file system is run on the first 
storage media partition to store and manage files. 

30 Similarly, a second file system is run on the sec- 
ond storage media partition to store and manage 
files. The first and second storage media partitions 
may be part of a same computer system, may 
merely constitute separate storage devices or may 

35 even be separate computers. The second file sys- 
tem differs from the first file system. A distributed 
file system is provided. The distributed file system 
furnishes a distributed name space that includes 
files in the first storage media partition and files in 

40 the second storage media partition. The distributed 
file system furnishes name resolution services to 
the first file system and the second file system. 
The distributed file system is transparent to the 
first file system and the second file system. 

45 In accordance with a further aspect of the 

present invention, a distributed system runs a first 
network operating system on a computer system 
and a second network operating system on a com- 
puter system. The second network operating sys- 

50 tern differs from the first network operating system. 
A distributed file system is provided over the net- 
work operating systems and furnishes the distrib- 
uted system with a unified distributed name space 
of files. The distributed file system furnishes name 

55 resolution services to the network operating sys- 
tems. The distributed name space includes files 
stored on the computer system that runs the first 
network operating system and files stored on the 
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computer system that runs the second network 
operating system. The distributed file system is 
transparent to the network operating systems. 

In accordance with a still further aspect of the 
present invention, a distributed system has multiple 
components. The components of the distributed 
system are logically partitioned into domains. Each 
domain is self-contained such that it may operate 
independently of other domains. The distributed 
system runs a network operating system in a first 
domain that implements a security policy. The do- 
main implements a security policy that differs from 
the first security policy and is independent of the 
distributed file system. 

In accordance with an additional aspect of the 
present invention, a method is practiced in the 
distributed system. In this method, a distributed file 
system provides a distributed name space. At least 
one underlying file system is provided in the dis- 
tributed system for performing file system oper- 
ations. Objects upon which file system operations 
may be performed are visible in the distributed 
name space and at least one object upon which file 
system operations may not be performed is also 
visible in the distributed name space. 

Brief Description of the Drawings 

Figure 1 is a block diagram of a distributed 
system for practicing a preferred embodiment of 
the present invention. 

Figure 2 is a more detailed block diagram of a 
domain controller of Figure 1. 

Figure 3 illustrates a simplified example of dis- 
tributed name space for the preferred embodiment 
of the present invention. 

Figure 4 is a flow chart illustrating the steps 
performed by an access object routine in the pre- 
ferred embodiment of the present invention. 

Figure 5 is a more detailed block diagram of a 
workstation in accordance with the preferred em- 
bodiment of the present invention. 

Figure 6 is a flow chart of a retrieve storage 
location routine used in the preferred embodiment 
of the present invention. 

Figure 7 is a flow chart of the perform server 
name resolution routine of the preferred embodi- 
ment of the present invention. 

Figure 8 is a diagram illustrating the format of 
the prefix table in the preferred embodiment of the 
present invention. 

Figure 9 is a flow chart of the steps performed 
by the get referral routine in the preferred embodi- 
ment of the present invention. 

Figure 10 is a flow chart of steps performed by 
the initialize domain root volume local information 
routine of the preferred embodiment of the present 
invention. 



Figure 11 is a block diagram of a domain 
controller in accordance with the preferred embodi- 
ment of the present invention. 

Figure 12 is a flow chart of the initialize domain 
5 non-root volume local information routine of the 
preferred embodiment of the present invention. 

Figure 13 is a flow chart illustrating the steps 
performed by the initialize interdomain information 
routine of the preferred embodiment of the present 
io invention. 

Figure 14 is a flow chart of the steps per- 
formed by the initialize workstation prefix table of 
the preferred embodiment of the present invention. 

Figure 15 is a flow chart of the steps per- 
J5 formed by the initialize domain controller prefix 
table routine of the preferred embodiment of the 
present invention. 

Detailed Description of the Invention 

20 

A preferred embodiment of the present inven- 
tion provides a distributed file system. The distrib- 
uted file system of the preferred embodiment of 
the present invention is implemented by compo- 

25 nents distributed across a distributed system. The 
distributed file system provides logical transpar- 
ency for named objects in the file system so that 
the path names of objects in the system are not 
intrinsically tied to their physical location. In addi- 

30 tion, the distributed file system organizes a name 
space for the distributed system into a single logi- 
cal tree structure. The distributed file system parti- 
tions the distributed system into administrative do- 
mains (which will be described in more detail be- 

35 low) which may each implement separate admin- 
istrative and security policies. The security policy 
practiced by a domain may be independent of the 
distributed file system. The distributed file system 
provides a super structure for "tying" together por- 

40 tions of the distributed system having heteroge- 
neous file systems and heterogeneous network op- 
erating systems. The distributed file system pro- 
vides name resolution services to the file systems 
and the network operating system, but the distrib- 

45 uted file system is transparent to the file systems 
and the network operating system. 

Figure 1 is a block diagram of a distributed 
system 100 that is suitable for practicing the pre- 
ferred embodiment of the present invention. Those 

50 skilled in the art will appreciate that the distributed 
system configuration shown in Figure 1 is merely 
illustrative. Other distributed system configurations 
may also be used to practice the present invention. 
The distributed system 100 includes worksta- 

55 tions 101, input/output (I/O) devices 102, network 
servers 103, secondary storage devices 104, and 
domain controllers 106. The workstations 101 and 
networks servers 103 may include internal mem- 
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ory, a processor, and other components. The net- 
work servers 103 run network operating systems. 
The secondary storage devices 104 may include 
disk drive devices or other suitable secondary stor- 
age components. It should be appreciated that 
software and data are stored within the internal 
memory of the workstations 101 and the domain 
controllers 106. In addition, software and data are, 
likewise, stored in the secondary storage devices 
104. 

The components included in the distributed 
system 100 are logically partitioned into domains 
108A, 108B and 108C, wherein each domain in- 
cludes a subset of the hardware and software com- 
ponents of the distributed system 100. Each do- 
main may include one or more networks running 
network operating systems. A domain 108A, 108B 
or 108C may correspond with an administrative 
portion of an organization. A domain 108A, 108B 
and 1 08C is a self-contained and self-sufficient unit 
for purposes of administration and security. Do- 
mains facilitate scaling of the distributed system 
100 so that components may be readily added or 
removed from the system. 

In order to more fully understand the notion of 
a "domain," it is helpful to consider an example. 
Suppose that a distributed system is used in a 
corporation having multiple departments. In such 
an environment, a first domain contains the hard- 
ware and software components of the corporation's 
product development department, whereas a sec- 
ond domain contains the hardware and software 
components of the corporation's marketing depart- 
ment. A third domain contains the hardware and 
software components of the corporation's finance 
department, and a fourth domain contains the hard- 
ware and software components of the corporation's 
sales department. 

Each domain includes at least one domain 
controller 106. Multiple domain controllers 106 may 
be provided within each domain (see domain 108B, 
for example) so as to enhance availability and to 
provide load balancing of domain controller re- 
sources. Each domain controller is a distinguished 
machine. Figure 2 is a block diagram showing 
several major functional components of a domain 
controller 200. Each domain controller within the 
distributed system 100 includes the functional com- 
ponents shown in Figure 2 as well as additional 
components. The functional components within 
each domain controller 200 include directory ser- 
vice (DS) entries 202, which provide directory ser- 
vice information. Each domain controller also in- 
cludes a directory service (DS) server 204. The DS 
server 204 is responsible for mediating access to 
the DS entries 202. The DS entries 202 provide the 
naming service for the distributed file system and 
are described in more detail in copending applica- 



tion entitled "Unification of Directory Services With 
File System Services," which is assigned to a 
common assignee with the present application. 
A key distribution center (KDC) 206 is provided 

s in the domain controller 200 and plays a role in 
maintaining security within the domain. A distrib- 
uted file system (DFS) manager 208 is provided in 
the domain to manage knowledge about the distrib- 
uted file system and the volumes (described in 

w more detail below) contained within the domain. 
The distributed file system manager 208 also pro- 
vides functionality for facilitating distributed name 
resolution. Distributed name resolution involves re- 
solving a name in a distributed name space to a 

15 physical address. The distributed file system man- 
ager 208 additionally provides management for a 
prefix table (described in more detail below) and 
management for knowledge about the file system. 
Before discussing the distributed file system in 

20 more detail, it is helpful to first introduce several 
concepts. An "object" is a logical structure that 
includes data structures for holding data and may 
include functions that operate on data held in the 
data structures. An object may hold just data with- 

25 out including any functions. In the distributed file 
system, both hardware components and software 
components may be modeled as objects. Modeling 
the data processing resources as objects insulates 
programs from needing to know the particulars of 

30 the resource. 

The objects provided within the distributed sys- 
tem 100 are stored in file system constructs known 
as "volumes". The volumes are organized hierar- 
chically (as will be described in more detail below). 

35 A volume is a unit of physical storage supporting a 
file system and a set of files and directories which 
comprise a persistent store of objects. Each do- 
main has its own volumes that hold objects for the 
domain and that define a name space that is local 

40 to the domain. 

Each volume has an associated volume object 
that holds information that allows distributed name 
resolution to be performed on the volume. Each 
volume object describes a single volume with a 

45 single entry path. The information includes an entry 
path to the volume and the identity of a file server 
for handling requests to access the volume. Vol- 
ume objects also store the entry paths for domains 
immediately superior to and immediately subordi- 

50 nate to the domain containing the volume object. 
Entry paths for all volumes in the domain contain- 
ing the volume are also stored therein. 

The names of objects in the distributed system 
are organized into a distributed name space. Figure 

55 3 shows a simplified example of such a distributed 
name space 300 for a distributed system. The 
distributed file system makes the distributed name 
space visible. The distributed name space 300 is a 
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single logical tree structure that graphically repre- 
sents the named objects of the distributed system. 
The single tree structure provides a place for cen- 
tralizing knowledge about the system and facilitates 
access to the entire name space. The distributed 
file system hides junctions between machines and 
domain so that the distributed system appears 
seamless. Thus, the differences between file sys- 
tems present in the system and the differences 
between network operating systems present in the 
system are hidden in the distributed name space. 
Each name in the distributed name space 300 
corresponds to an object within the distributed sys- 
tem. The domain folder objects each correspond 
with a domain controller. Each arc (see Figure 3) of 
the distributed name space 300 corresponds to a 
portion of a path in the name space. The objects 
visible in the distributed name space need not all 
be file system objects; rather, non-file system ob- 
jects that are not available for file system oper- 
ations, such as a remote procedure call (RPC) 
server 358, may also be present in the distributed 
name space. 

The objects in the distributed name space may 
be divided by domain as shown in Figure 3 (note 
Domains W, X, Y and Z). It is worth noting that not 
all objects need be part of a security policy of a 
domain. Hence, there may be machines, collec- 
tions of objects or peripherals that lie outside trust 
policies of any domain. For instance, RPC server 
358 is not part of a domain. The objects in a 
domain form a sub-tree of the distributed name 
space. Thus, domain X includes domain folder ob- 
ject 320, directory object 322, volume object 324 
and server object 326. Domain Y includes domain 
folder object 328, workstation object 330, directory 
object 332, document object 334 and volume ob- 
ject 336. Domain W includes domain folder object 
306, volume object 338, document object 340, di- 
rectory object 342 and document object 344. Do- 
main W also includes directory object 346. Direc- 
tory object 346 contains document objects 350 and 
352. Lastly, Domain Z includes domain folder ob- 
ject 308, workstation object 304, volume object 354 
and document object 356. 

The logical path name identifies an object, vol- 
ume or other component within the distributed 
name space 300. The distributed file system of the 
preferred embodiment of the present invention pro- 
vides a vehicle for resolving the logical path name 
to a physical address. 

The objects held for each domain may be 
divided into one or more volumes. For example, 
domain Y includes volume 310. Domain X includes 
volume 312; domain W includes volumes 314 and 
316; and domain Z includes volume 318. 

Two volumes are connected via logical con- 
structs known as "junction points." Junction points 



are composed of an "entry point" and an "exit 
point." An "entry point" is a logical path name 
which corresponds to the root of the name space 
for a volume or domain. For example, the logical 

5 path name "\b\c" corresponds to the root of vol- 
ume 310 which is logically contained within domain 
Y. An "exit point" is a logical path name which 
corresponds to a point in the distributed name 
space at which another volume is attached. For 

io example, the logical path name "\a" is an exit point 
from volume 312 of domain X into volume 314 of 
domain W. In the preferred embodiment, a given 
volume can have multiple exit points but can only 
have one entry point. "External junction points" join 

rs name spaces which are not available for file sys- 
tem operations with the distributed name space 
300. In Figure 3, an external junction point joins 
name space 319 with volume 312. It should be 
appreciated that external junction points permit glu- 

20 ing of external name spaces into the distributed file 
system. 

"Logical roots" are programming invariants that 
refer to a point in the distributed name space 300. 
Logical roots are used to gain access to files and 

25 objects through the distributed name space 300. 
Logical roots are context-sensitive in that a same 
logical root may resolve to different addresses on 
different machines. Logical roots typically identify 
the root of a domain, the root of a machine's name 

30 space, or the root of all domains. Logical roots are 
shortcuts for directly accessing an object in the 
tree that forms the distributed name space 300 
without having to traverse the direct lineal ancestor 
objects. For example, Figure 3 illustrates that the 

35 logical path name "\b\c" is an entry point into 
domain Y. Such a logical path name may be asso- 
ciated with a logical drive letter such as "D:\," in 
order to create a logical root. In this way, logical 
path names, such as "\b\c\d", may be accessed 

40 using the path name "D:\d". Hence, the distributed 
name space 300 of Figure 3 may be traversed 
beginning at an object other than logical root node 
302. Logical roots are used to access objects 
throughout the distributed name space. 

45 As mentioned above, the preferred embodi- 
ment of the present invention uses these logical 
path names (which may include a logical root) to 
access objects in the distributed system 100 (Fig- 
ure 1). Figure 4 illustrates (from a high level per- 

50 spective) the steps performed to access an object 
when a request to access the object when a re- 
quest to access the object originates at a work- 
station. Copies of the access object routine are 
preferably stored on all workstations 101 of the 

55 distributed system 100 and on all domain control- 
lers 106 of the distributed system 100. Initially a 
request to access an object is received (step 402). 
For purposes of illustration, suppose that the re- 
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quest originates from workstation 500 shown in 
Figure 5. The workstation 500 includes an in- 
put/output (I/O) unit 502, a central processing unit 
(CPU) 504, and a memory 506. In addition, the 
workstation 500 is connected to a keyboard 508 
and a mouse 510. The workstation memory 506 
holds a copy of a workstation operating system 
512, and at least one application program 514. The 
operating system 512 includes the access object 
routine 516; and a local file system driver 526 that 
is responsible for managing the local file system. 
The memory 500 also holds four other routines 
518, 522, 524 and 526 which will be described in 
more detail below. 

The request to access the object is forwarded 
to the CPU 504 of workstation 500. The CPU 504 
executes the access object routine 516 and begins 
processing to fulfill the request. The request may 
originate from the application program 514 or from 
the operating system 512. For example, suppose 
that a query request is entered on keyboard 508 or 
on mouse 510. The query request to query an 
object is received by the input/output unit 302, 
which transfers the query request to the CPU 504. 
The CPU 504 extracts a logical path name of the 
object to be accessed (step 404). The logical path 
names, rather than the physical addresses, are 
provided by such requests. Accordingly, the logical 
path name must be converted into a physical ad- 
dress in the distributed system 100 that identifies 
where the object is stored (step 406). In other 
words, distributed name resolution must be per- 
formed. The operations entailed in this step will be 
discussed in more detail below. The object at the 
resulting physical address is then accessed (step 
408). It should be appreciated that the object may 
be located in the same domain as the workstation 
or may be located remotely at another domain or 
generally outside the domain. 

The distributed file system performs the dis- 
tributed name resolution required by step 406. Fig- 
ure 6 is a flow chart of a retrieve storage location 
routine 518 which performs the mapping of the 
logical path name of an object to a physical ad- 
dress for the object in the distributed system 100 
(i.e., step 406 of Figure 4). Copies of the retrieve 
storage location routine 518 are preferably stored 
in all of the workstations 101 (Figure 1) and domain 
controllers 106 of the distributed system 100. 

Initially, the retrieve storage location routine 
518 receives the request to retrieve information 
from the distributed system 100 (step 602). For 
purposes of illustration, it is assumed that the re- 
trieve storage location routine 518 of the work- 
station 500 receives the request to retrieve the 
information from a local site in the distributed sys- 
tem 100. The logical path name for the object to be 
accessed is obtained from the request (step 604). 



A workstation prefix table 520 of the workstation 
500 is searched to determine if an entry for the 
logical path name obtained from the request is 
stored (step 606) in the prefix table. 

5 The workstation prefix table 520 is only one 

example of a prefix table data structure. Each do- 
main controller 106 includes a prefix table as well. 
Figure 8 shows the format of a prefix table 800 in 
more detail. The prefix table 800 acts as a cache 

ro for holding addresses for logical path names that 
have already been resolved. The prefix table 800 is 
used to map logical path names of objects into 
physical addresses in the distributed system. It 
should be appreciated that volumes have asso- 

15 dated volume objects and hardware components 
typically have associated objects that receive re- 
quests to access the volumes and components, 
respectively. A separate row or entry 802 is pro- 
vided for each logical path name held within the 

20 prefix table 800. Each row 802 includes a number 
of columns 804. Each column 804 holds a separate 
field. Column 806 holds the logical path name that 
uniquely identifies an object within the distributed 
name space. Column 808 holds a string associated 

25 with the logical path name of column 806 that is 
meaningful to an underlying network operating sys- 
tem (such as Microsoft LAN Manager, sold by 
Microsoft Corporation of Redmond, Washington). 
The distributed file system of the preferred em- 

30 bodiment of the present invention is not a tradi- 
tional network operating system but rather is in- 
dependent of the network operating system and 
serves as a super-structure for tying together in- 
dividual network operating systems. 

35 Column 810 holds a local address that is 
meaningful to a local network operating system 
server or to a local file system. Column 812 holds 
a local volume flag. The local volume flag indicates 
whether the logical path name of the row 802 

40 identifies a volume of the workstation that the user 
is logged onto. Column 81 4 holds a local exit point 
flag. The local exit point flag indicates whether the 
logical path name of the row 802 represents an exit 
point for a local volume. Column 816 holds a 

45 referral service flag that indicates whether the logi- 
cal path name of the row 802 represents a logical 
path name for a domain folder object. Lastly, col- 
umn 818 holds an inter-domain volume flag. The 
inter-domain volume flag is set whenever the vol- 

50 ume having the logical path name of the row 802 is 
stored in a domain outside of the domain contain- 
ing the prefix table. 

If all the logical path names of the distributed 
name space 300 for the distributed system 100 

55 were stored in the workstation prefix table 520, 
then the mapping of the logical path name for the 
object would only entail a simple lookup of the 
logical path name and a retrieval of the corre- 
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sponding address. However, as the distributed sys- 
tem 100 expands into a system with thousands or 
even tens of thousands of hardware and software 
components modeled as corresponding named ob- 
jects, the distributed name space 300 expands 
correspondingly. Management of a single prefix 
table for such an extensive distributed system be- 
comes impractical due to the sheer size of such a 
prefix table. 

In step 606, the retrieve storage location rou- 
tine 518 searches the workstation prefix table 520 
for the longest logical path name which is a prefix 
of the logical path name from the request. In other 
words, the workstation 500 first wants to discover 
whether it already possesses the requisite knowl- 
edge to complete name resolution for the logical 
name. The notion of a prefix for a logical path 
name is perhaps best explained by example. For 
example, "\a\b" is a prefix of logical path name 
"\a\b\c". The longest matching prefix found in step 
606 may be equivalent to the entire logical path 
name or may match only a leading portion of the 
logical path name. In step 608, the retrieve storage 
location routine 520 determines if there was a 
match between the logical path name from the 
request and a logical path name in the workstation 
prefix table 520 (i.e., was there a prefix that 
matched a leading portion of the logical name). If 
there was a match, it is determined whether the 
matched entry in the workstation prefix table 520 
has its local volume flag set in column 812 (step 
610). In other words, it is determined whether the 
object having the logical path name is within a local 
volume for the workstation. If the local volume flag 
is set, the local address is retrieved from column 
810 of the prefix table and the logical path name 
from the request is translated by substituting the 
retrieved local address for the matched portion of 
the logical path name (step 612). Control is then 
returned to the access object routine 516 (see 
Figure 4). 

If in step 610 it is determined that the matched 
entry does not have its local volume flag set, the 
workstation 500 must look elsewhere to resolve the 
logical name to a physical address and, hence, the 
network address associated with the logical path 
name is retrieved from column 808 in the work- 
station prefix table 520 (step 614). The request to 
access the object is then sent indirectly to a net- 
work server at the retrieved network address (step 
616). The request is actually sent to a redirector 
that then sends the request to the network server. 
The perform server name resolution routine 522 is 
then called to perform name resolution at the serv- 
er (step 618). 

Figure 7 shows a flow chart of the steps per- 
formed by the perform server name resolution rou- 
tine 522. A logical path name is obtained from the 



request to access the object that is sent to the 
server (step 702). The network server 103 deter- 
mines whether the path refers to local volumes 
(step 706). If the path is within the local volumes of 

5 the network server 103, name resolution is per- 
formed by the network server 103 (step 708). The 
network server accesses the information held in the 
server's prefix table to perform name resolution. 
Upon completion of step 708, the perform server 

w name resolution routine 522 returns processing 
control to the retrieve a storage location routine 
518. 

If in step 706 it is determined that there was 
not a match between the logical path name and 

75 any of entries in the server prefix table for a local 
volume, a distinguished error is returned to the 
originating workstation to indicate that the logical 
path name from the request is outside the distrib- 
uted name space included within any local volume 

20 on the server (step 710). Upon completion of step 
710, processing control is returned to the retrieve a 
storage location routine 518 at step 620. 

After the server name resolution routine 522 is 
performed (step 618), a determination is made 

25 whether the server returns a distinguished error 
(step 620). If the server returns a distinguished 
error, a working prefix table entry (identifying the 
prefix table entry that is currently of interest) is set 
as the entry in the prefix table of the server where 

30 the match occurred (step 622). 

In step 624, a determination is made whether 
the working prefix table entry refers to a domain 
controller and, hence, can issue referrals. A referral 
is a packet of information about a volume that 

35 includes an entry path for the volume, a provider ID 
that identifies a file system driver that may be 
called to access the volume and a service address 
that is either given to a network provider to talk 
with the distributed file system or refers to another 

40 addressing mechanism. A determination is made 
whether the working prefix table entry has its refer- 
ral service flag (column 816) set. If the working 
prefix table entry indicates that referrals cannot be 
issued, the working prefix table entry is changed to 

45 the entry in the prefix table which contains the next 
longest logical path name that is a prefix of the 
logical path name from the request (step 626). 
Processing then repeats, as described above, be- 
ginning with step 624. These steps look for the 

50 next best prefix to find a domain controller that can 
issue a referral. 

In step 624, if the working prefix table entry 
indicates that referrals can be issued (i.e., the 
working prefix table entry refers to a domain con- 

55 tainer), then in step 628, a get referral routine 524 
is called to get a referral (step 628). This routine 
will be described in more detail below. The work- 
station then stores the information derived from the 
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referral in the prefix table 520 (step 630). 

If at step 608 it is determined that the prefix 
table does not contain a matching prefix for the 
logical path name contained within the request, the 
workstation 500 then looks for help from the do- 
main controller. Specifically, the working prefix ta- 
ble entry is set to refer to the prefix table of the 
domain controller of the domain containing the 
workstation from which the request originated (step 
632). The steps described above beginning at step 
624 are then repeated at the domain controller until 
the logical path name is resolved to an address. 

Figure 9 is a flowchart of the steps performed 
by the get referral routine 524. Initially, in step 902, 
the request for a referral is received at the domain 
controller associated with the working prefix table 
entry, The logical path name for the object to be 
accessed is extracted from the request (step 904). 
The prefix table at the domain controller that re- 
ceived the request is searched under the control of 
the DFS manager 208 for the longest logical path 
name which is a prefix of the logical path name 
from the referral request is searched (step 906). A 
determination is then made if there is a match 
between any of the prefixes in the table and the 
logical path name (step 908). If there is not a 
match, then in step 908, a referral is constructed 
by obtaining the network address (i.e., held in 
column 808 of the prefix table) for the domain 
controller of the immediately superior domain (step 
910). The referral is sent from the domain control- 
ler to the workstation that requested the referral 
(step 920). Control then returns to the retrieve a 
storage location routine 518. 

If in step 908 it is determined that there is a 
match, then it is determined whether the matched 
logical path name refers to a volume outside the 
domain of the domain controller, by checking 
whether the inter-domain volume flag is set as 
"False" (step 912). If the inter-domain volume flag 
is set as "False", a referral is constructed from the 
matched prefix table entry (step 913) and the refer- 
ral is forwarded to the workstation holding the de- 
sired volume (step 920). If the inter-domain volume 
flag is set to "True", then processing continues 
with step 914. 

In step 91 4, the referral service flag is checked. 
If the referral service flag is set to "False", the 
prefix table of the domain controller is searched for 
the longest logical path name which is a prefix of 
the logical path name in the currently matched 
prefix table entry (step 916). Processing continues 
by repeating step 914 (described above). 

If in step 914 it is determined that the referral 
service flag is set to "True", a referral is con- 
structed by obtaining the network address of the 
domain controller from the currently matched prefix 
table entry (step 918). Upon completion of step 



918, processing continues with step 920 wherein a 
referral is sent to the workstation which requested 
the referral. Control then returns to the retrieve a 
storage location routine 518. 

5 As mentioned above, prefix tables are stored in 

each workstation 101 and each domain controller 
106. Each variety of prefix table must be initialized. 
The prefix table of a domain controller is initialized 
with data retrieved from volume objects represent- 

70 ing volumes in the domain, which stores the cor- 
responding domain folder object. 

Figure 15 illustrates the steps performed by an 
initialize a domain controller prefix table routine 
1104, which initializes prefix tables in domain con- 

75 trailers using data stored in volume objects. Figure 
11 illustrates several components of a domain con- 
troller 1100 that are used in such initialization. In 
step 1502, the initialize domain's root volume local 
information routine 1106 is called. Figure 10 illus- 

20 trates the step performed by this routine 1106. In 
step 1001, the entry path of the domain's root 
volume is retrieved from the volume object of the 
root volume for the domain containing the domain 
controller 109. An entry is created in the domain 

25 controller prefix table 1102 and the retrieved entry 
path is stored in the created entry (step 1 003). The 
local address of the root volume is retrieved from 
the volume object of the root volume and the local 
address is stored in the entry (step 1005). The 

30 local volume flag 812 in the entry is set (step 
1007). In step 1009, the network address of the 
domain's root volume is retrieved from the volume 
object of the root volume, and the network address 
is set (step 1007) in the entry of the domain 

35 controller prefix table 1 102. In step 101 1 , the refer- 
ral service flag 816 in the entry of the domain 
controller prefix table 907 is set. The volume object 
is searched for the domain's root volume to deter- 
mine if unprocessed exit points for the domain's 

40 root volume still exist (step 1013). Exit points for 
the domain root volume are determined by simply 
examining the entries loaded into the prefix table of 
the domain controller for all domain volume ob- 
jects. If unprocessed exit points exist in the volume 

45 object, processing continues with steps 1015 
through 1021. 

In step 1015, the first unprocessed exit point is 
retrieved from the volume object for the domain's 
root volume. In step 1017, it is determined whether 

50 there is an entry in the domain controller prefix 
table 1102 for the exit path of the retrieved exit 
point. If there is not an entry in the domain control- 
ler prefix table 1102 for the exit path, then an entry 
is created in the domain controller prefix table 1 1 02 

55 for the exit path of the retrieved exit point. Upon 
completion of step 1019, processing continues with 
step 1021. If in step 1017, an entry in the domain 
controller prefix table 907 for the exit path of the 
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retrieved exit point is found, processing continues 
with step 1021. In step 1021, the local exit point 
flag for the entry containing the exit path for the 
exit point retrieved in step 1015 is set. Upon com- 
pletion of step 1021, processing continues with 
step 1013. 

In step 1013, it is determined whether all exit 
points for the domain's root volume have been 
processed. If not, control returns to the initialize a 
domain controller prefix table routine 1104. 

Once the domain controller prefix table 1102 
has been initialized with the domain's root volume 
local information, the initialize a domain controller 
prefix table routine 1104 invokes the initialize a 
domain's non-root volume local information routine 
1108 (step 1504). This routine 1108 retrieves the 
entry path and network address of the non-root 
volume from each volume object for a non-root 
volume of the domain. In addition, this routine 
stores each retrieved entry path and network ad- 
dress in the domain controller prefix table 1102. 

Figure 12 illustrates the preferred steps of the 
initialize a domain's non-root volume local informa- 
tion routine 1108. A determination is made whether 
any unprocessed volume objects for non-root vol- 
umes in the domain still exist (step 1202). If un- 
processed volume objects exist, the entry path for 
the non-root volume is retrieved (step 1203) and a 
determination is made whether there is already an 
entry in the domain controller prefix table 1102 for 
the entry path of the non-root volume associated 
with the first unprocessed volume object (step 
1204). If there is not an entry in the domain control- 
ler prefix table 1102 for the entry path of the non- 
root volume, an entry is created in the domain 
controller prefix table 1102 (step 1210). The entry 
path of the non-root volume is retrieved from the 
volume object for the non-root volume (step 1212). 
The entry path is stored in the created entry of the 
domain controller prefix table 1102 (step 1214). 
Upon completion of step 1213, processing contin- 
ues with step 1206. If in step 1204, it is determined 
that the domain controller prefix table 1204 con- 
tains an entry for the entry path of the non-root 
volume, processing 1102 continues with step 1206. 
In step 1206, the network address of the non-root 
volume is retrieved from the volume object. The 
retrieved network address is stored in the entry of 
the domain controller prefix table 1102 containing 
the entry path for the non-root volume (step 1208). 
Upon completion of step 1208, processing contin- 
ues again with step 1202. 

If in step 1202 it is determined that all volume 
objects for non-root volumes have been processed, 
then control returns to the initialize a domain con- 
troller prefix table routine 1 1 04. 

Now that the domain controller prefix table 
1102 has been initialized with the domain's root 



volume local information (step 1502) and the do- 
main's non-root volume local information (step 
1504), the initialize a domain controller prefix table 
routine 1104 invokes an initialize inter-domain in- 

5 formation routine 1110 (step 1 506). 

Figure 13 is a flow chart of the steps per- 
formed by the initialize inter-domain information 
routine 1110 that is called in step 1506. Initially, a 
determination is made whether unprocessed vol- 

10 ume objects remain which represent a root volume 
for a domain which is immediately superior to or 
immediately subordinate to the domain containing 
the domain controller (step 1302). If unprocessed 
volume objects remain, the entry path for the cor- 

75 responding root volume is retrieved from the first 
unprocessed volume object (step 1304). Next, it is 
determined whether there is an entry in the domain 
controller prefix table 1102 for the entry path of the 
root volume (step 1306). If there is not such an 

20 entry, an entry in the domain controller prefix table 
1102 is created (step 1308). The retrieved entry 
path is then stored in the created entry of the 
domain controller prefix table 1102 (step 1312). 
Upon completion of step 1312, processing contin- 

25 ues with step 1314. If in step 1306 it is determined 
that there is an entry in the domain controller prefix 
table 1102 for the entry path of the root volume, 
then processing continues with step 1314. 

In step 1314, the network address of the root 

30 volume is retrieved from the volume object. The 
retrieved network address is stored in the entry of 
the domain controller prefix table 1102 containing 
the retrieved entry path (step 1316). The referral 
service flag is set and the inter-domain volume flag 

35 is set in the entry containing the retrieved entry 
path (step 1318). Upon completion of step 1318, 
processing continues with step 1302. 

If in step 1302 it is determined that all volume 
objects for root volumes of immediately superior 

40 and immediately subordinate domains have been 
processed, control returns to the initialize a domain 
controller prefix table routine 1104. 

Upon return of processing control from the 
initialize inter-domain information routine 1110, the 

45 initialize domain controller prefix table routine 1 1 04 
ends processing. While processing related to the 
initialize a domain controller prefix table routine 
ceases, processing may continue on the domain 
controller. 

50 A prefix table in a workstation of the distributed 
system 100 is initialized with the entry point and 
exit points for each volume stored on the work- 
station, as well as the entry point of its domain. 
The preferred data to store in the prefix table 

55 of a workstation is persistently stored on and re- 
trieved from the workstation itself. The persistently 
stored data includes the entry path of each volume 
on the workstation; the entry path of the domain 
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containing the workstation, along with the physical 
address of the domain controller of the domain; 
and the physical address of any storage device 
local to the workstation. 

Figure 14 illustrates the preferred steps of a 5 
routine to initialize a workstation prefix table. In 
step 1402, the routine to initialize a workstation 
prefix table determines if the workstation prefix 
table has been initialized with information about all 
local volumes on the workstation. If unprocessed 10 
local volumes still remain, the routine retrieves the 
entry path of the unprocessed local volume from 
persistent storage on the workstation. The retrieved 
entry path is stored in the workstation prefix table 
(step 1404). The local address of the unprocessed 75 
local volume is retrieved from persistent storage 
and the local address is stored address in the 
prefix table (step 1406). The local volume flag is 
set in the workstation prefix table (step 1408). A 
determination is then made whether the workstation 20 
prefix table has been initialized with information 
about all exit points for this local volume on the 
workstation. If the workstation prefix table has not 
been initialized with information about all exit points 
for this local volume, information about the first 25 
unprocessed exit point is retrieved from permanent 
storage (step 1412). In step 1414 it is determined if 
there is an entry in the workstation prefix table for 
the exit path of the retrieved exit point. If there is 
not an entry in the workstation prefix table, an entry 30 
is then created in the workstation prefix table for 
the exit path of the retrieved exit point (step 1416). 
Upon completion of step 1416, processing contin- 
ues with step 1418. If in step 1414 it is determined 
that there is an entry in the workstation prefix table 35 
for the exit path of the retrieved exit point, process- 
ing continues with step 1418. 

In step 1418, the local exit point flag is set for 
the entry in the workstation prefix table that con- 
tains the exit path for the retrieved exit point. Upon 40 
completion of step 1418, processing continues with 
step 1410 again 

If in step 1410 it is determined that the work- 
station prefix table has been initialized with in- 
formation about all exit points for this local volume, 45 
then processing continues with step 1402. 

If in step 1402 it is determined that the work- 
station prefix table has been initialized with in- 
formation about all local volumes on the work- 
station, then the entry path of the root volume for 50 
the domain containing the workstation is retrieved 
(step 1420). In step 1422, the network address of 
the domain controller for the root volume of the 
domain containing the workstation is retrieved. An 
entry is created in the workstation prefix table and 55 
the retrieved entry path is stored in the retrieved 
network address in the entry (step 1424). In step 
1426, the referral service flag is set for the created 



entry in the workstation prefix table. 

Thus, it will be appreciated that, although a 
specific embodiment of the invention has been 
described herein for purposes of illustration, var- 
ious modifications may be made without departing 
from the spirit and scope of the invention. Accord- 
ingly, the invention is not limited except as by the 
appended claims. 

Claims 

1. In a distributed system having a distributed 
name space of objects wherein each object 
has both a logical name uniquely identifying 
the object in the distributed name space and a 
corresponding address, the objects being 
grouped into logical domains which are or- 
ganized into a hierarchical structure wherein 
each domain may have one superior domain in 
the hierarchical structure and one or more sub- 
ordinate domains in the hierarchical structure, 
a computer implemented method for accessing 
an object comprising the steps of: 

providing a domain controller component 
for each domain, each domain controller com- 
ponent holding a prefix table which stores an 
entry for a logical name in the distributed 
name space of a domain controller component 
for any immediately superior domain and an 
entry for the logical name in the distributed 
name space for any domain controller compo- 
nent in any immediately subordinate domain, 
each said entry including an address of the 
domain controller component; 

providing a first computer component for 
processing requests for information from the 
distributed system, the first computer compo- 
nent including another prefix table which stores 
entries for prefixes of logical names in the 
distributed name space and each entry in- 
cludes an address of an object in the distrib- 
uted system that is named by the prefix; 

receiving a request to access the object at 
the first computer component, wherein the re- 
quest includes a logical name for the object to 
be accessed in the distributed system; 

determining if an entry for a prefix of the 
logical name from the request is stored in the 
prefix table of the first computer component; 

in response to a determination that an en- 
try for a prefix of the logical name is not stored 
in the prefix table of the first computer compo- 
nent, 

retrieving from the prefix table of the first 
computer component the address of the do- 
main controller component for the domain con- 
taining the first computer component; 

sending the logical name from the request 
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to the domain controller component for the 
domain containing the first computer compo- 
nent; 

retrieving from the prefix table of the do- 
main controller component for the domain con- 
taining the first computer component, an ad- 
dress corresponding to the logical name from 
the request; and 

accessing the object at the retrieved ad- 
dress corresponding to the logical name from 
the request. 

2. The method of claim 1 wherein the first com- 
puter component may directly access objects 
in a local address space and wherein said 
method further comprises the steps of: 

in response to a a determination that an 
entry for a prefix of the logical name is stored 
in the prefix table of the first computer compo- 
nent; 

identifying a longest matching prefix 
among the prefixes having entries in the prefix 
table of the first computer component; 

determining whether an object associated 
with the longest matching prefix is stored in 
the local address space that is directly acces- 
sible by the first computer component; 

where it is determined that the object as- 
sociated with the longest matching prefix is 
stored in the local address space obtaining an 
address for a portion of the memory; and 

accessing the object using the obtained 
address for the portion of memory. 

3. The method of claim 2 wherein the distributed 
system includes a network server and the 
method further comprises the steps of: 

where it is determined that the object as- 
sociated with the longest matching prefix is not 
stored in the local address space that is di- 
rectly accessible by the first computer compo- 
nent, 

forwarding the request to access the ob- 
ject to the network server; and 

attempting to resolve the logical name to 
an address at the network server. 

4. The method of claim 3, further comprising the 
step of where the resolution of the logical 
name to an address at the network server is 
successful, using the address to access the 
object. 

5. The method of claim 4, further comprising the 
steps of: 

where the resolution of the logical name of 
an address at the network server is not suc- 
cessful, 



retrieving from the prefix table of the first 
computer component the address of the do- 
main controller component for the domain con- 
taining the first computer component; 
5 sending the logical name from the request 

to the domain controller component for the 
domain containing the first computer compo- 
nent; 

retrieving from the prefix table of the do- 
io main controller component for the domain con- 

taining the first computer component, an ad- 
dress corresponding to the logical name from 
the request; and 

accessing the object at the retrieved ad- 
75 dress corresponding to the logical name from 

the request. 

6. The method of claim 1 wherein the address of 
the domain controller component for the do- 

20 main containing the first computer component 

is retrieved without broadcasting a request for 
the physical address. 

7. The method of claim 1 wherein the step of 
25 providing a domain controller component in- 
cludes the step of retrieving the logical names 
and the corresponding addresses of the do- 
main controller components for the immedi- 
ately superior domain and the immediately 

30 subordinate domains, wherein the method fur- 
ther comprises the steps of storing the re- 
trieved logical names and corresponding ad- 
dresses in the prefix table of the domain con- 
troller component. 

35 

8. The method of claim 1 wherein the logical 
name is a logical path name. 

9. In a distributed system having its components 
40 logically partitioned into self-contained do- 
mains, wherein each domain includes a do- 
main controller holding information about what 
is included in the domain and included in said 
components is a workstation having local stor- 

45 age, a method comprising the steps of: 

providing a distributed file system that fur- 
nishes a distributed name space for objects in 
the distributed system; 

receiving a request at the workstation to 
so access an object in the distributed name 

space, said request identifying the object by 
its logical name in the distributed name space; 

providing a first cache of logical names 
and associated resolved addresses at the 
55 workstation; 

accessing the first cache at the workstation 
to locate a longest matching portion of the 
logical name of the object to which access is 
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requested that has already been resolved to an 
address; 

where it is determined by accessing the 
first cache that a portion of the logical name 
has not already been resolved to an address, 

forwarding the request to a domain con- 
troller for the domain that contains the work- 
station; 

providing a second cache at the domain 
controller of associated resolved addresses for 
logical names; 

accessing the second cache to determine 
if a portion of the logical name of the object to 
which access is requested has already been 
resolved to an address; 

where it is determined by accessing the 
second cache that a portion of the logical 
name of the object to which access is re- 
quested has been resolved to an address, 

forwarding the portion of the logical name 
and the address to the workstation; 

storing the portion of the logical name and 
the address in the first cache at the work- 
station; and 

repeating the above steps beginning with 
the accessing the first cache step. 

10. The method of claim 9, further comprising the 
steps of: 

where it is determined by accessing the 
first cache that a portion of the logical name of 
the object to which access is requested has 
already been resolved to an address, 

determining whether the address of the 
portion of the logical name refers to a storage 
location in the local storage of the workstation; 
and 

where the address portion of the portion of 
the logical name refers to a storage location in 
the local storage of the workstation, accessing 
the object using the address of the portion of 
the logical name. 

11. The method of claim 10 wherein the distrib- 
uted system further comprises a network serv- 
er and the method further comprises the steps 
of: 

where it is determined that the address of 
the portion of the logical name refers to a 
storage location outside local storage of the 
workstation, 

forwarding the logical name to the network 
server; and 

attempting name resolution of the logical 
name in an address at the network server. 

12. The method of claim 11, further comprising the 
steps of where the name resolution at the 



network server is successful in resolving the 
logical name to an address, using the address 
to access the object. 

5 13. The method of claim 1 1 , further comprising the 
steps of: 

where the name resolution at the network 
server is not successful in resolving the logical 
name to an address, 
w forwarding the logical name to a second 

domain controller for a domain which includes 
the portion of the distributed name space iden- 
tified by the portion of the logical name that 
was determined to be resolved by examining 
75 the first cache at the workstation; 

providing another cache of logical names 
and associated resolved addresses at the sec- 
ond domain controller; 

accessing the cache at the second domain 
20 controller to find an address for a portion of the 

logical name that has already been resolved; 

forwarding the found address to the work- 
station; and 

storing the found address and associated 
25 portion of the logical name in the first cache at 

the workstation. 

14. In a distributed system having a first storage 
media partition and a second storage media 

30 partition, a method comprising the steps of: 

running a first file system on the first stor- 
age media partition of the distributed system 
for storing and managing files; 

running a second file system on the sec- 

35 ond storage media partition for storing and 

managing files, wherein the second file system 
differs from the first file system; and 

providing a distributed file system that fur- 
nishes a single distributed name space with 

40 files in the first storage media partition and 

files in the second storage media partition and 
that furnishes name resolution services to the 
first file system and the second file system for 
the distributed name space, wherein the dis- 

45 tributed file system is transparent to the first 

file system and the second file system. 

15. A distributed system comprising at least one 
storage media comprising: 

so a first storage media partition running a 

first file system for storing and managing files; 

a second storage media partition running a 
second file system for storing and managing 
files, said second file system differing from the 
55 first file system; and 

a distributed file system for supplying file 
name resolution services for the file systems 
and for furnishing a single distributed name 
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space that includes files from the first storage 
media partition and files from the second stor- 
age media partition wherein the distributed file 
system is transparent to the first file system 
and the second file system. 

16. In a distributed system having computer sys- 
tems with files stored therein, a method com- 
prising the steps of: 

running a first network operating system 
on one of the computer systems; 

running a second network operating sys- 
tem on one of the computer systems wherein 
the network operating system differs from the 
first network operating system; and 

providing a distributed file system over the 
network operating systems that furnishes name 
resolution services to the first network operat- 
ing system and the second network operating 
system and furnishes a unified distributed 
name space for the distributed system, 
wherein said name space includes files stored 
on the computer system running the first net- 
work operating system and files stored on the 
computer system running the second network 
operating system and wherein the distributed 
file system is transparent to the first network 
operating system and the second network op- 
erating system. 

17. A distributed system comprising: 

computer systems having files stored 
therein, at least one of said computer systems 
running a first network operating system and at 
least one of said computer systems running a 
second network operating system that differs 
from the first network operating system; and 

a distributed file system layered over the 
network operating systems for furnishing name 
resolution services to the first network operat- 
ing system and the second network operating 
system and for providing a distributed name 
space of files, wherein said distributed name 
space includes files stored on the computer 
system running the first network operating sys- 
tem and files stored on the computer system 
running the second network operating system 
and wherein the distributed file system is 
transparent to the first network operating sys- 
tem and the second network operating system. 

18. In a distributed system having multiple compo- 
nents, a method comprising the steps of: 

logically partitioning the components of the 
distributed system into domains, including a 
domain, each domain being self-contained 
such that it may operate independently of oth- 
er domains; 



providing a distributed file system for fur- 
nishing name resolution services; 

running at least one network operating 
system in the first domain, the network operat- 
5 ing system implementing a first security policy; 

and 

implementing a second security policy on 
the first domain that differs from the first secu- 
rity policy, said second security policy being 
w independent of the distributed file system. 

19. In a distributed system, a method comprising 
the steps of: 

providing a distributed file system that pro- 
75 vides a distributed name space; 

providing at least one underlying file sys- 
tem for performing filing system operations; 

making objects upon which file system op- 
erations may be performed visible in the dis- 
20 tributed name space; and 

making at least one object which file sys- 
tem operations may not be performed visible 
in the distributed name space. 

25 20. In a distributed system organized hierarchically 
into logical domains, including a first domain 
and a second domain, a method comprising 
the steps of: 

providing a distributed name space of ob- 

30 jects wherein each object has a logical name 
that identifies the object within the name space 
and a corresponding address; 

providing a domain controller for each do- 
main, each domain controller holding a prefix 

35 table storing entries wherein each entry holds 

an address for a corresponding prefix of a 
logical name; 

receiving a request to access an object in 
the first domain from the second domain; 

40 providing a first referral in the prefix table 

in the domain controller of the second domain 
that refers to the domain controller in the first 
domain; 

accessing the prefix table in the domain 
45 controller of the second domain to obtain the 

first referral that refers to the domain controller 
in the first domain; 

providing a second referral in the prefix 
table in the domain controller in the first do- 
so main; 

using the first referral to access the prefix 
table in the domain controller in the first do- 
main to obtain the second referral; and 

using the second referral to access the 
55 object. 

21. The method of claim 21 wherein the distrib- 
uted system includes a third domain and the 
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second referral refers to a logical name in the 
third domain. 

22. The method of claim 21 wherein the distrib- 
uted system includes a network server in the 
first domain wherein the second referral refers 
to the network server in the first domain and 
wherein the step of using the second referral 
to access the object comprises the step of 
using the second referral to access the net- 
work server in the first domain and accessing 
the object via the network server. 
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